OLE Db z Delphree - stav?
Otázka od: Karel Kral
13. 11. 2002 15:31
Chtel bych se zeptat Zbyska Hlinky, v jakem stavu je jeho OLE Db. Stahl
jsem si z Delphree posledni verzi, je dost stara a tak mi pripada, ze ji
uz asi nevyvijis.
Na Ole Db jsem se dostal proto, ze potrebuji exportovat do MS SQL 2000
velike mnozstvi dat a pres ADO neni rychlost vubec dobra. (D7 Pro)
--
______________________________________________________
Karel Kral, vedouci odd. IT / IT dep. manager
Purus, s.r.o., Cezavy 627, 664 56 Blucina, CZ
Tel: 547 235 000, 602 552 432, Fax: 547 231 203
E-Mail: mailto:kral@purus.cz, WWW: http://www.purus.cz
______________________________________________________
Odpovedá: Zbysek Hlinka
13. 11. 2002 15:53
On 13 Nov 2002 at 14:54, Karel Kral wrote:
> Chtel bych se zeptat Zbyska Hlinky, v jakem stavu je jeho OLE Db.
> Stahl jsem si z Delphree posledni verzi, je dost stara a tak mi
> pripada, ze ji uz asi nevyvijis.
>
> Na Ole Db jsem se dostal proto, ze potrebuji exportovat do MS SQL 2000
> velike mnozstvi dat a pres ADO neni rychlost vubec dobra. (D7 Pro) --
Takze jsem umistil na Delphree aktualni verzi OLE DB. Oproti
predchozi je tam hodne veci jinak, takze nebude chodit prakticky nic
z verze 0.6.
Jinak s vyvojem koncim, protoze to uz umi vsechno, co potrebuji pro
sve veci, a uz s timto nebudu zacinat zadne nove projekty.
Samozrejme nebranim nikomu, aby se v tom stoural a vylepsoval to.
S pozdravem
Zbysek Hlinka
E-mail: hlinka@hlinka.cz, localizator@localizator.com
Phone: +420 603 551 282
Odpovedá: Erik Salaj
14. 11. 2002 1:15
> Na Ole Db jsem se dostal proto, ze potrebuji exportovat do MS SQL 2000
> velike mnozstvi dat a pres ADO neni rychlost vubec dobra. (D7 Pro)
urcite zrychlenie v ADO sa da dosiahnut pomocou tzv. ADO Recordset binding,
ktore umoznuje nepouzivat varianty ale udaje citat/ukladat priamo do
vytvorenych
pametovych buffrov (komponentu s prikladom mame v Adonis-e je to ale
univerzalne
pouzitelne v ADO). Dalsia moznost zrychlenia by mohlo byt pouzitie MS SQL
2000
DTS (Data Transformation Services) objektov.
Erik
Odpovedá: Karel Kral
14. 11. 2002 12:41
O Adonisu jsem taky uvazoval. Cetl jsem zde v konf., ze nemuze byt na
jednom pocitaci s ADOExpress. Je to pravda? Pripada mi to divne.
Jinak jsem projekt meril profilerem a zjistil jsem, ze ted (pote, co
jsem optimalizoval plneni parametru pro SP) zabira 50% vseho casu pri
exportu volani TADOCommand.Execute. A tam se obavam, ze neni co
optimalizovat.
Zkousel jsem taky testovaci program od Zbyska. Testoval jsem jeho
programem SpeedTest OLE Db, ADOExpress, ADO a ADOExpress + stored proc.
A zjistil jsem, ze ADOExpress + stored proc s parametry je temer stejne
rychla jako OLE Db, ktera vklada klasicky pomoci ExecSql INSERT INTO...
Problem je, ze ja tech parametru predavam 100 a to asi nejaky cas
sebere.
Erik Salaj wrote:
>
> > Na Ole Db jsem se dostal proto, ze potrebuji exportovat do MS SQL 2000
> > velike mnozstvi dat a pres ADO neni rychlost vubec dobra. (D7 Pro)
>
> urcite zrychlenie v ADO sa da dosiahnut pomocou tzv. ADO Recordset binding,
> ktore umoznuje nepouzivat varianty ale udaje citat/ukladat priamo do
> vytvorenych
> pametovych buffrov (komponentu s prikladom mame v Adonis-e je to ale
> univerzalne
> pouzitelne v ADO). Dalsia moznost zrychlenia by mohlo byt pouzitie MS SQL
> 2000
> DTS (Data Transformation Services) objektov.
>
> Erik
--
______________________________________________________
Karel Kral, vedouci odd. IT / IT dep. manager
Purus, s.r.o., Cezavy 627, 664 56 Blucina, CZ
Tel: 547 235 000, 602 552 432, Fax: 547 231 203
E-Mail: mailto:kral@purus.cz, WWW: http://www.purus.cz
______________________________________________________
Odpovedá: Erik Salaj
14. 11. 2002 19:59
> O Adonisu jsem taky uvazoval. Cetl jsem zde v konf., ze nemuze byt na
> jednom pocitaci s ADOExpress. Je to pravda? Pripada mi to divne.
niektore komponenty v Adonise maju rovnaky nazov ako v ADOExpresse,
preto nie je mozne pouzivat obidva baliky sucasne v rovnakom projekte
(ani nevidim dovod na to). Pre dany projekt je treba v Delphi jednoducho
zaskrtnut a pouzivat jeden z tychto balikov.
> Jinak jsem projekt meril profilerem a zjistil jsem, ze ted (pote, co
> jsem optimalizoval plneni parametru pro SP) zabira 50% vseho casu pri
> exportu volani TADOCommand.Execute. A tam se obavam, ze neni co
> optimalizovat.
> Zkousel jsem taky testovaci program od Zbyska. Testoval jsem jeho
> programem SpeedTest OLE Db, ADOExpress, ADO a ADOExpress + stored proc.
> A zjistil jsem, ze ADOExpress + stored proc s parametry je temer stejne
> rychla jako OLE Db, ktera vklada klasicky pomoci ExecSql INSERT INTO...
> Problem je, ze ja tech parametru predavam 100 a to asi nejaky cas
> sebere.
snad vyskusat to DTS, alebo napada ma aj moznost vytvorit programovo
na SQL serveri storovanu proceduru, ktora bude obsahovat vsetky inserty
a tu spustit, alebo vygenerovat vsetky INSERTY do SQL skriptu a spustit
skript. MS SQL obsahuje BULK INSERT prikaz, ten by mal byt najrychlejsi,
dokonca rychlejsi ako bcp (bulk copy) utilita. Pri velkom mnozstve udajov
je z hladiska rychlosti vyhodne aj zrusit vsetky indexy, udaje vlozit a
indexy
opetovne vytvorit.
Erik